As is known, application programming interfaces (APIs) specify how software components interact with each other. This may include, for example, the specification of interfaces for accessing the features of libraries and software development kits (SDKs) or services for building applications. Web APIs enable the development of web applications, typically by simply combining services that can be invoked remotely via protocols such as the hyper test transfer protocol (HTTP). Applications such as these oftentimes have a small amount of client-side logic and sometimes are referred to as “mash-ups.” There are number applications that rely on Web APIs. One current popular example of a type of applications that generally relies on Web APIs is the mobile application, frequently referred to simply as an “app.” Vendors of Web APIs frequently publish their APIs on the Web and/or otherwise make their Web APIs available. Revenue can be generated by charging consumers when they consume the published APIs, for instance.
There are several challenges when it comes to publishing and charging for API consumption. Such challenges may relate to, for example, tracking the API calls, the identification of the consumer for each call, etc. These problems sometimes are solved by API management systems. There are several API management system products that include basic API management system capabilities. Such products are available from, for example, Mashery, MuleSoft, Apigee, 3Scale, Apify, Axway Mashape, and Apiary.io.
A good API management system may allow an API provider to publish its API and make it available for the intended consumers. APIs can be published on the Web, within an organization to provide access to organization internal services, etc., and published APIs can be searched or browsed by the intended API consumers. Once a consumer has identified an API fulfilling a set of requirements, the consumer can register as a consumer. During registration, the consumer may be provided with the details for invoking the APIs such as, for example, the endpoints where the API can be accessed and a so-called API key.
An API key generally must be provided when an API is called, and it typically is checked by the API management system. On a successful check, the call is booked under the registered consumer that owns the API key. Identifying the registered consumer based on the API key typically is a prerequisite for charging a consumer and rejecting unauthorized calls. Besides simple unencrypted API keys, some API management systems also support more advanced techniques, potentially providing for higher levels of protections like digital signatures, certificates, OAuth tokens, and/or the like.
In a large-scale environment, the self-service aspect can become particularly important. This includes the self-support through communities, as well as the automated selling of API consumption contracts. Therefore, some API management systems provide self-service through techniques including communities and developer portals.
To simplify the offering of APIs, some API management systems provide the ability to bundle APIs into API domains. API domains, also known as API packages, API products, etc., can be provided with capabilities like access policies including service-level agreements (SLAs). For example, the usage of an API can be restricted to a certain number of calls that can be performed by a given consumer within a given time period.
In existing API management systems, API domains generally are defined by API providers. For defining API domains that are useful for consumers, information concerning how consumers are using the APIs can be beneficial. This at least implies that providers should know, for example, which APIs are consumed together and could therefore be put into an API domain and offered to consumers.
Certain example embodiments help solve the issue of identifying which APIs are consumed together and could therefore be put into an API domain and offered to consumers. More particularly, certain example embodiments involve an approach to detecting useful groups of APIs for defining API domains, e.g., based on monitoring API consumption. The monitored API consumption may in certain example embodiments may include, for example, consumer registration data, data resulting from tracking API calls, and/or the like.
One aspect of certain example embodiments relates to an API management system automatically detecting API domains by analyzing registration data and API invocation events.
Another aspect of certain example embodiments relates to an API domain detection process that combines detected domains by analyzing API invocation events with already registered domains.
Another aspect of certain example embodiments relates to an API management system with an event bus between API gateways and registry/repository, e.g., to enable a complex event processing (CEP) based implementation of the API domain detection process. Alternatively, or in addition, storing API invocation events may be stored in an event store to run the API domain detection process on-demand.
Still another aspect of certain example embodiments relates to an approval process that collects the feedback from an API provider for API domains and API domain extensions.
Still another aspect of certain example embodiments relates to approval process that in essence asks API consumers if they are interested in any of the API domain and API domain extension proposals.
Yet another aspect of certain example embodiments relates to governing API domains via a lifecycle model that includes, for example, state change policies for triggering the approval processes.
Yet another aspect of certain example embodiments relates to an automatic detection mechanism for API domains and, with the help of CEP techniques, being able to expand this detection into several new features including, for example, the governing of API domains via a lifecycle model that may include state change policies for triggering the approval processes.
In certain example embodiments, an application programming interface management system. APIs that each have a native endpoint are provided. Gateways provide virtual endpoints to respective APIs, and are configured to identify consumers attempting to access the APIs and forward API calls for authorized consumers to the native endpoints. A registry is stored on a non-transitory computer readable storage medium. The registry stores (a) registration information indicating which consumers have registered for which APIs, (b) metadata that includes information concerning operations supported by, and native and virtual endpoint information for, the APIs, and (c) runtime data from the gateways for at least API call type events, with the runtime data including, for each API call type event, a timestamp, a consumer identifier, a location, and an identifier of the API being called. A communications channel is defined between the gateways and the registry, with the communications channel being configured to transmit runtime data from the gateways to the registry. Processing resources comprise at least one processor and a memory are configured to detect API domains by analyzing the registration information and the runtime data from the gateways, with each said detected API domain including at least two of the APIs. For a given detected API domain, an indication is received as to whether the respective detected API domain is approved of by a provider of the APIs included therein, and in response to the respective detected API domain being approved of by the provider, the respective detected API domain is registered with the registry by storing in the registry metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective detected API domain.
According to certain example embodiments, the processing resources may be further configured to respond to a consumer registering for a plurality of APIs by at least: generating API domain proposals by analyzing the registration information and the runtime data from the gateways, each said API domain proposal including at least two of the APIs; and for each said API domain proposal; receiving first input indicating whether the respective domain proposal is approved of by a provider of the APIs included therein; in response to the respective domain proposal being approved of by the provider, receiving second input indicating whether the respective domain proposal is accepted by the consumer registering for the APIs; and in response to the respective domain proposal being approved of by the provider and accepted by the consumer registering for the APIs, registering the respective domain proposal with the registry as an API domain by storing in the registry registration information indicating that the consumer has registered for the respective API domain, and by storing metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective API domain.
According to certain example embodiments, the processing resources may be further configured to at least analyze the runtime data from the gateways by applying at least one set of one or more rules thereto in order to identify APIs that likely are consumed together and thus should be included in an API domain proposal presented for approval by the provider of the APIs therein. At least one of said set of rules may group together APIs that are invoked by the same consumer and from the same location, optionally additionally based on whether they occurred within a predetermined timeframe.
According to certain example embodiments, the processing resources may be further configured to filter API domain proposals based on the registration data, e.g., so that a given API domain proposal is presented as a detected API domain only if there are a predetermined number of consumers who have each registered for the all of the APIs in that given API domain proposal.
According to certain example embodiments, the processing resources may be further configured to at least generate a proposal for extending an already-existing API domain if a detected domain includes a superset of the APIs included in that already-existing API domain.
According to certain example embodiments, the processing resources may be further configured to at least subject the events on an event channel to complex event processing (CEP) queries, e.g., with the CEP queries including continuous queries that, through windowing, identify time-based relations between different API call type events. For instance, CEP queries may at least: identify related API call type events; create domain detection events in response to the identification of related API call type events; filter created domain detection events based on the runtime data and the registration data; and generate events corresponding to domain proposals and/or domain extension proposals in response to the filtering.
According to certain example embodiments, the gateways may be further configured to provide service-level agreement (SLA) enforcement.
According to certain example embodiments, the registry may be configured to enforce a predefined domain lifecycle in connection with API domains, the predefined domain lifecycle optionally being defined in accordance with one or more associated policies and/or possibly specifying when proposed API domains should be automatically approved by a provider and/or accepted by a consumer.
In certain example embodiments, a method of managing application programming interfaces is provided. Gateways providing virtual endpoints to APIs that have respective native endpoints are provided, with the gateways being configured to identify consumers attempting to access the APIs and forward API calls for authorized consumers to the native endpoints. In a registry provided on a non-transitory computer readable storage medium, there is stored (a) registration information indicating which consumers have registered for which APIs, (b) metadata that includes information concerning operations supported by, and native and virtual endpoint information for, the APIs, and (c) runtime data from the gateways for at least API call type events, with the runtime data including, for each API call type event, a timestamp, a consumer identifier, a location, and an identifier of the API being called. API domains are detected (e.g., via at least one processor) by analyzing the registration information and the runtime data from the gateways, with each said detected API domain including at least two of the APIs. For at least some of the detected API domains, the method further includes (e.g., using at least one processor for): receiving an indication as to whether the respective detected API domain is approved of by a provider of the APIs included therein; and in response to the respective detected API domain being approved of by the provider, registering the respective detected API domain with the registry by storing in the registry metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective detected API domain.
In certain example embodiments, a method of managing application programming interfaces is provided. Gateways providing virtual endpoints to APIs that have respective native endpoints are provided, with the gateways being configured to identify consumers attempting to access the APIs and forward API calls for authorized consumers to the native endpoints. In a registry provided on a non-transitory computer readable storage medium, there is stored (a) registration information indicating which consumers have registered for which APIs, (b) metadata that includes information concerning operations supported by, and native and virtual endpoint information for, the APIs, and (c) runtime data from the gateways for at least API call type events, with the runtime data including, for each API call type event, a timestamp, a consumer identifier, a location, and an identifier of the API being called. The method further includes responding to a consumer registering for a plurality of APIs by (e.g., using at least one processor to) at least: generating API domain proposals by analyzing the registration information and the runtime data from the gateways, each said API domain proposal including at least two of the APIs; and for at least some of said API domain proposals, receiving first input indicating whether the respective domain proposal is approved of by a provider of the APIs included therein; in response to the respective domain proposal being approved of by the provider, receiving second input indicating whether the respective domain proposal is accepted by the consumer registering for the APIs; and in response to the respective domain proposal being approved of by the provider and accepted by the consumer registering for the APIs, registering the respective domain proposal with the registry as an API domain by storing in the registry registration information indicating that the consumer has registered for the respective API domain, and by storing metadata including information concerning operations supported by, and native and virtual endpoint information for, the respective API domain.
In certain example embodiments, there are provided non-transitory computer readable storage mediums tangibly storing instructions that, when executed by at least one processor of a computer system, perform the above-described and/or other methods.
Similarly, in certain example embodiments, a computer system including a processor, a memory, and a non-transitory computer readable medium, is configured to execute computer functions for accomplishing the above-described and/or other methods. For instance, in certain example embodiments, a computer system including a processor, a memory, and a non-transitory computer readable medium, may host a master gateway registry configured to at least perform the above-described and/or other methods.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.